Детектирование сбоев

Дмитрий Масленников, «Т-Банк»

Прямые и косвенные методы детектирования сбоев

«Прямой метод» — когда тестируем наш функционал
«Косвенный метод» — когда видим аномальные значения в показателях, которые сами по себе не говорят о сбое

Прямые методы

Ручное тестирование

В настоящее время — в основном для подтверждения подозрения на сбой

Автотесты

  • Автотесты можно делать на продакшен
  • Наиболее быстрый и точный способ детектировать сбои
  • Редко дают ложно-положительный результат
  • Относительно «дороги» в разработке
  • Полезность часто недооценивается

Автотесты в Sage

  • Для мониторинга системы процессинга логов пишем специальные логи «heartbeats»
  • Эти логи проходят точно такой же путь обработки и индексирования
  • Позволяют отличить ситуации, когда пользователи перестали писать логи, от ситуаций, когда сломалась обработка логов
  • Можно увидеть потери части логов
  • Доверяем метке времени и можно замерять время обработки (от записи до появления в поиске)

Автотесты в Google Search

  • Тестирование популярных запросов, с известным стабильным результатом, например "wikipedia"
  • Запросы на новостные, популярные, непопулярные и очень редкие сайты, чтобы проверить все категории
  • Позволяют проверить не только поиск, но и ранжирование

Автотесты Jira

  • Полный цикл:
    • Создание проекта
    • Заведение задач
    • Поиск
    • Удаление
    • и т.п.

Инструменты тестирования

  • Prometheus Blackbox Exporter
  • Selenium
  • Любые библиотеки тестирования на любом языке программирования
  • Ваш любимый язык программирования

Самодиагностика

Сообщения об ошибках

  • Часто в ошибки записывают, то, что ошибкой не является
    «Недостаточно средств» — не ошибка, а обычная ситуация
  • Путают некорректные запросы и ошибки в приложении
  • Непроработанные ошибки приложения приводят к ложным результатам детектирования сбоев

Сообщения об ошибках

  • Классификация HTTP кодов возврата — хорошая точка для старта
    • 1XX, 2XX, 3XX — успешно отработавшие запросы
    • 4XX — запросы, которые в принципе не корректны (баг в клиенте или ошибка пользователя)
    • 5XX — в процессе обработки потенциально корректного запроса произошла ошибка
  • С точки зрения мониторинга клиента полезно четко отделить внутренние ошибки от ошибок пришедших от зависимостей

Общая самодиагностика приложения

  • Liveness-endpoint
  • Полноценные системы самодиагностики
    • Похожи на автотесты, но тестируют скрытые особенности систем, например целостность шардов, корректность настроек, отрабатывание скрытых процессов обслуживания

Общая самодиагностика приложения

Полноценные системы самодиагностики

  • Похожи на автотесты, но тестируют скрытые особенности систем, например целостность шардов, корректность настроек, отрабатывание скрытых процессов обслуживания
  • Google тестирует наличие нужных индексов интернет
  • Kibana показывает состояние шардов и реплик
  • SQL сервера имеют развитые инструменты самодиагностики
  • JRE имеет много средств для самодиагностики

Косвенные (статистические) методы

Жалобы пользователей

  • Через каналы поддержки
  • Специальные сервисы (downdetector и похожие)
  • Социальные платформы (соц. сети и более узкоспециальные площадки)

Отклонения от сезонности в телеметрии

  • Настроенные вручную пороги на значения или их производные
  • Машинное обучение

Достоинства

  • Покрывает сразу очень широкий срез функционала

Недостатки

  • Работает только при достаточном количестве статистики
    • Проблема в ночных работах обнаружится только утром
    • Есть важный редко используемый функционал (например, только в период сдачи налоговой отчетности)

Недостатки

  • Один «странный» пользователь портит всю статистику
  • В целом большая шумность метода

Недостатки

  • Отклонение в статистике не означает сбоя — всегда нужна дополнительная диагностика
  • Даже, если срабатывание верное, то не понятно, в чем дело

Выводы

  • Нужен комплексный подход
  • Диагностику сбоев надо специально проектировать
  • В любом случае иногда будете пропускать сбой (утешительный вывод)

Алертирование

Инженерам не надо смотреть в мониторы непрерывно

Алертирование — механизм привлечения внимания инженеров
  • Алертируем о сбоях
  • Алертируем о возникновении ситуации требующей немедленного внимания

Триггер и пейдж

Типичные ошибки

Нарушение обратной связи

  • Алертирование настраивают не те, кто реагирует на алерты
  • Алерты доставляются не инженерам, которые устраняют сбои

Типичные ошибки

Замусоривание алертов

  • Посылаем информационные сообщения вместо алертов
  • Во время сбоя приходит сотни и тысячи сообщений

При правильной организации алертирования ответственные реагируют на каждый пейдж

Типичные ошибки

Доставка алерта большому кругу лиц

  • Может породить коллективную безотвественность
  • Постоянно реагирую одни и те же лица

Типичные ошибки

Доставка алерта узкому кругу наиболее опытных лиц

  • Остальная команда не развивается
  • Опытные выгорают
  • Bus-factor

Типичные ошибки

Недостаточно настойчивая доставка алертов

  • Телефон должен звонить
  • Получение и работу над алертом надо подтверждать
  • При неподтверждении должен быть установлен процесс эскалации

Спасибо!

Вопросы?